Data processing systems, such as, computer systems, are composed of a variety of different components or “devices” that operate together to form the resultant system. Typically, some of the devices are supplied with the computer system initially, such as a central processing unit and a communication bus, and some devices can be installed into the computer system after the initial configuration of the system. In any event, in the general case, each device has an associated driver that, among other functions, configures the device and allows the device to be operable within the overall system. Drivers are typically software instructions that can be loaded into the computer system's memory and when executed will communicate with the device to properly configure the device for operation. The driver may initialize the device so that the device can function and the driver may also allow the device to communicate normally within the overall system.
In certain system configurations, a device driver may support multiple devices. During the initialization of a computer system, the system may enumerate the devices installed within the system. As a result, multiple instances of a driver may be loaded to support multiple devices. In order to avoid loading multiple instances of the same driver, in the past, a driver developer had to know how to determine whether another instance of the same driver is loaded. For example, when an instance of a driver is initialized, the driver has to acquire a lock to a device dictionary maintained by a kernel of an operating system to prevent others from accessing the same. Once the driver acquires the lock, the driver accesses the dictionary to determine whether another instance of the device driver has already registered its driver handle. If not, the current instance of driver registers with the dictionary by inserting its driver handle. If there is a previous driver registered with the dictionary, the current instance of the driver may unload itself. Thus, this is a first-come-first-serve situation where multiple instances of the same driver race to acquire the lock and register with the dictionary. In addition, a driver has to maintain the dictionary. Such a mechanism is relatively complicated and inconvenient, and an author of a device driver must write this software each time they write a driver.
Further, in certain situations, a driver may have to invoke another driver to perform certain functionalities that the driver is not capable of doing so. In the past, one driver has to call another driver via a communication protocol, such as, those described in IEEE 1275 finnware standard (“IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices” IEEE Std 1275-1994, Oct. 28, 1994, pp. 1-262), which requires a driver developer to fully understand such a protocol and the system software has to fully support it.